docs/USB Flashing.md

   1 # USB Flashing
   2
   3 Modern flight controllers are typically flashed in USB DFU mode. This is a straight-forward process in Configurator. The standard flashing procedure should work successfully with the caveat of some platform specific matters as noted below.
   4
   5 * If the board is placed in DFU mode manually (by hardware button), then check "No reboot sequence"
   6 * Baudrate is not relevant for DFU flashing.
   7 * For version upgrades, enable "Full chip erase"
   8
   9
  10 ## Platform Specific: Linux
  11
  12 Linux requires `udev` rules to allow write access to USB devices for users.
  13
  14
  15 ### Simple unconditional rule
  16
  17 The simplest rule is to allow DFU access unconditionally; this avoids having to set up specific groups which may be distro independent. If you have previously flashed OpenTX or EdgeTX you will already have such a rule as `/etc/udev/rules.d/45-companion-taranis.rules` and no further action is required. Otherwise, you can add (as root) a file for example `/etc/udev/rules.d/45-stdfu-permissions.rules` containing the single line:
  18
  19 ```
  20 SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE:="0666"
  21 ```
  22
  23 ### More complex group example
  24
  25 As an alternative, you can make a distro specific rule restricting DFU a group; an example shell command to achieve this on Ubuntu is:
  26
  27 ```
  28 (echo '# DFU (Internal bootloader for STM32 MCUs)'
  29  echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0664", GROUP="plugdev"') | sudo tee /etc/udev/rules.d/45-stdfu-permissions.rules > /dev/null
  30 ```
  31
  32 This assigns the device to the `plugdev` group(a standard group in Ubuntu). To check that your account is in the `plugdev` group type `groups` in the shell and ensure `plugdev` is listed. If not you can add yourself as shown (replacing `<username>` with your username):
  33 ```
  34 sudo usermod -a -G plugdev <username>
  35 ```
  36 Then log out and back again to acquire the new group.
  37
  38 On Arch and its derivatives the group would be `uucp` (in the rule and the `usermod` command:
  39 ```
  40 sudo usermod -a -G uucp <username>
  41 ```
  42
  43 ## Platform Specific: Windows
  44
  45 The Configurator can have problems accessing USB devices on Windows. A driver should be automatically installed by Windows for the ST Device in DFU Mode but this doesn't always allow access. One solution is to replace the ST driver with a libusb driver. The easiest way to do that is to download [Zadig](http://zadig.akeo.ie/).
  46 With the board connected and in bootloader mode (reset it by sending the character R via serial, or simply attempt to flash it with the correct serial port selected in Configurator):
  47
  48 * Open Zadig
  49 * Choose Options > List All Devices
  50 * Select `STM32 BOOTLOADER` in the device list
  51 * Choose `WinUSB (v6.x.x.x)` in the right hand box
  52
  53 ![Zadig Driver Procedure](assets/images/zadig-dfu.png)
  54
  55 * Click Replace Driver
  56 * Restart the Configurator (make sure it is completely closed, logout and login if unsure)
  57 * Now the DFU device should be seen by Configurator
  58
  59
  60 ## Using `dfu-util`
  61
  62 `dfu-util` is a command line tool to flash ARM devices via DFU. It is available via the package manager on most Linux systems or from [source forge](http://sourceforge.net/p/dfu-util).
  63
  64 Put the device into DFU mode by **one** of the following:
  65
  66 * Use the hardware button on the board
  67 * Send a single 'R' character to the serial device, e.g. on POSIX OS using `/dev/ttyACM0` at 115200 baudrate.
  68
  69 ```
  70 stty 115200 < /dev/ttyACM0
  71 echo -ne 'R' > /dev/ttyACM0
  72 ```
  73 * Use the CLI command `dfu`
  74
  75 It is necessary to convert the `.hex` file into `Intel binary`. This can be done using the GCC `objcopy` command; e.g. for the notional `inav_x.y.z_NNNNNN.hex`.
  76
  77 ```
  78 objcopy -I ihex inav_x.y.z_NNNNNN.hex -O binary inav_x.y.z_NNNNNN.bin
  79 ```
  80
  81 You can now DFU flash the `.bin` file:
  82
  83 ```
  84 dfu-util -d 0483:df11 --alt 0 -s 0x08000000:force:leave -D inav_x.y.z_NNNNNN.bin
  85 ```
  86 or with full erase
  87
  88 ```
  89 dfu-util -d 0483:df11 --alt 0 -s 0x08000000:mass-erase:force:leave -D inav_x.y.z_NNNNNN.bin
  90 ```
  91
  92 ## Caveats
  93
  94 Once the board is placed in DFU mode, the hardware boot loader polls for activity on the USB device and *some MCU dependent* UARTS (often UART1 and UART3). If you have a device on one of these UARTS that transmits unconditionally (GPS, RX for example), then that port may win the "active device" race, and DFU flashing will fail.
  95
  96 Ensure that such devices are either disconnected or not powered during flashing.
  97
  98 ## Older devices / broken USB ports
  99
 100 If you have a older (unsupported) FC that does not support DFU, or a modern board with a broken USB port, it is possible to flash the board via a UART (typically UART1) using the ST serial flashing protocol.
 101
 102
 103 This is supported by (very) old Configurators, the open source [stm32flash](https://sourceforge.net/projects/stm32flash/) tool and some ST proprietary tools.
 104
 105 Examples:
 106
 107 * Erase the device (assumed `/dev/ttyUSB0`)
 108
 109 ```
 110 stm32flash -o -b 57600 /dev/ttyUSB0
 111 ```
 112 * Flash a HEX file (notionally `inav_x.y.z_NNNNNN.hex`)
 113
 114 ```
 115 stm32flash -w inav_x.y.z_NNNNNN.hex -v -g 0x0 -b 57600 /dev/ttyUSB0
 116 ```
 117
 118 replace `/dev/ttyUSB0` as appropriate for your OS. You will probably be more successful at 57600 baud than 115200. The speed is auto-detected by the FC.